feat(channels): add xiaoyi channel support by ystyle · Pull Request #875 · sipeed/picoclaw

ystyle · 2026-02-27T12:18:14Z

Summary

Add XiaoYiChannel in pkg/channels/xiaoyi/ subpackage following new channel architecture
Implement A2A (Agent-to-Agent) protocol using xiaoyi-agent-sdk
Use BaseChannel with factory registration pattern
Add XiaoYiConfig to config.go
Add documentation with link to Huawei official setup guide

Files Changed

pkg/channels/xiaoyi/init.go - Factory registration
pkg/channels/xiaoyi/xiaoyi.go - Channel implementation
pkg/config/config.go - Add XiaoYiConfig
pkg/channels/manager.go - Register xiaoyi in initChannels
cmd/picoclaw/internal/gateway/helpers.go - Blank import
docs/channels/xiaoyi/ - Documentation (zh/en)
README.md / README.zh.md - Update channel list
go.mod / go.sum - Add SDK dependency

Configuration

{
  "channels": {
    "xiaoyi": {
      "enabled": true,
      "ak": "your-access-key",
      "sk": "your-secret-key",
      "agent_id": "your-agent-id"
    }
  }
}

Hi @alexhoshina, thank you for the review!

Dockerfile changes: I've removed them in the latest commit (ae50335). The Dockerfile modifications were for local testing and should not be part of this PR.

HandleMessage signature: I checked the refactor/channel-system branch, the HandleMessage function signature in BaseChannel is:

go func (c *BaseChannel) HandleMessage( ctx context.Context, peer bus.Peer, messageID, senderID, chatID, content string, media []string, metadata map[string]string, senderOpts ...bus.SenderInfo, )

My implementation follows the same pattern as the telegram channel. I've also tested it locally - sending a message to XiaoYi and getting a response works correctly. Could you please double-check? Thanks!

You are correct, I was referring to the old function signature, my apologies.

ystyle · 2026-02-27T16:00:50Z

@alexhoshina Thanks for the feedback!

WhatsApp deleted? - No, WhatsApp is not deleted. The latest commit (ae50335) only adds xiaoyi channel. Could you please check the latest version? The changed files are:
- README.md, README.zh.md
- cmd/picoclaw/internal/gateway/helpers.go (only adds xiaoyi import)
- docs/channels/xiaoyi/ (new)
- go.mod, go.sum
- pkg/channels/manager.go
- pkg/channels/xiaoyi/ (new)
- pkg/config/config.go
sessionID parsing with : - The chatID format is sessionID:taskID only for outbound messages. The sessionID itself doesn't contain :, so parsing should be safe.
completed status vs long message fragmentation - Good point! The SendStatus("completed") is called after ReplyStream. If message fragmentation happens, the status might be sent too early. I should move the status call to ensure it's sent after all fragments. Let me check how other channels handle this.

ystyle · 2026-02-27T16:01:39Z

@alexhoshina Good point about message fragmentation!

Currently, XiaoYi channel doesn't implement MessageLengthProvider (no MaxMessageLength set), so the Manager won't split messages. The SDK handles the message internally.

However, if we need to support MaxMessageLength in the future, the SendStatus("completed") call would need to be moved - perhaps to a callback or we could implement a separate interface for post-send actions.

For now, the implementation works correctly without fragmentation. Should I:

Add a comment explaining this limitation?
Or remove SendStatus("completed") and let the SDK handle the final state?

What do you suggest?

alexhoshina · 2026-02-27T16:07:01Z

@alexhoshina Thanks for the feedback!

WhatsApp deleted? - No, WhatsApp is not deleted. The latest commit (ae50335) only adds xiaoyi channel. Could you please check the latest version? The changed files are:

README.md, README.zh.md

cmd/picoclaw/internal/gateway/helpers.go (only adds xiaoyi import)

docs/channels/xiaoyi/ (new)

go.mod, go.sum

pkg/channels/manager.go

pkg/channels/xiaoyi/ (new)

pkg/config/config.go

sessionID parsing with : - The chatID format is sessionID:taskID only for outbound messages. The sessionID itself doesn't contain :, so parsing should be safe.

completed status vs long message fragmentation - Good point! The SendStatus("completed") is called after ReplyStream. If message fragmentation happens, the status might be sent too early. I should move the status call to ensure it's sent after all fragments. Let me check how other channels handle this.

WhatsApp has been removed in RADEME, you can check the line numbers I've marked, but it's just a minor issue

yinwm · 2026-02-27T16:07:26Z

sessionID parsing with : - The chatID format is sessionID:taskID only for outbound messages. The sessionID itself doesn't contain :, so parsing should be safe.

Is xiaoyi need this chatID format?

- Add XiaoYiChannel in pkg/channels/xiaoyi/ subpackage - Implement A2A protocol using xiaoyi-agent-sdk - Use ReplyStream + SendStatus for long-task pattern - Add XiaoYiConfig to config.go - Register xiaoyi in manager.go initChannels - Add blank import in gateway helpers - Add documentation in docs/channels/xiaoyi/ - Update README.md and README.zh.md channel lists

ystyle · 2026-02-27T16:12:56Z

@alexhoshina Sorry for the confusion! You were right about WhatsApp.

I found the issue - when I added XiaoYi to the README.md description line, I accidentally replaced "WhatsApp" instead of appending "XiaoYi".

This has been fixed in the latest commit (693db82):

Before: Talk to your picoclaw through Telegram, Discord, DingTalk, LINE, or WeCom (missing WhatsApp)
After: Talk to your picoclaw through Telegram, Discord, WhatsApp, DingTalk, LINE, WeCom, or XiaoYi

Thank you for catching this! 🙏

ystyle · 2026-02-27T16:15:01Z

@yinwm Yes, the sessionID:taskID format is needed for XiaoYi channel because:

Inbound: SDK's OnMessage callback provides both sessionID and taskID
Outbound: When Agent replies, we need to call client.ReplyStream(taskID, sessionID, content) - so we need to extract both from chatID

The chatID passed through the message bus needs to carry both pieces of information, hence the sessionID:taskID format.

Alternative approaches:

Store taskID in metadata and only use sessionID as chatID
Use a custom struct instead of string

But the current : separator approach is simple and consistent with how other channels encode multiple IDs. Do you have a better suggestion?

nikolasdehor

Well-structured channel implementation that follows existing patterns. The author has been responsive to feedback. Additional observations: (1) SDK license: As alexhoshina noted, the xiaoyi-agent-sdk dependency needs a compatible license (picoclaw uses Apache-2.0). The SDK repo should have an explicit license file before this PR merges. (2) chatID separator robustness: The sessionID:taskID format parsed with SplitN(msg.ChatID, ":", 2) works only if sessionID never contains ':'. Consider using a different separator or storing taskID in metadata. (3) Context usage: c.HandleMessage(c.ctx, ...) uses the channel-level context rather than the per-message ctx. If the channel is stopped mid-processing, this could cancel in-flight messages prematurely. (4) Error wrapping: In Send, the error is wrapped as channels.ErrTemporary regardless of the actual error type. Some errors (invalid session) may be permanent. Good work overall — pending license resolution.

alexhoshina · 2026-02-28T04:47:18Z

Well-structured channel implementation that follows existing patterns. The author has been responsive to feedback. Additional observations: (1) SDK license: As alexhoshina noted, the xiaoyi-agent-sdk dependency needs a compatible license (picoclaw uses Apache-2.0). The SDK repo should have an explicit license file before this PR merges. (2) chatID separator robustness: The sessionID:taskID format parsed with SplitN(msg.ChatID, ":", 2) works only if sessionID never contains ':'. Consider using a different separator or storing taskID in metadata. (3) Context usage: c.HandleMessage(c.ctx, ...) uses the channel-level context rather than the per-message ctx. If the channel is stopped mid-processing, this could cancel in-flight messages prematurely. (4) Error wrapping: In Send, the error is wrapped as channels.ErrTemporary regardless of the actual error type. Some errors (invalid session) may be permanent. Good work overall — pending license resolution.

Note that pico uses the MIT license

- Change chatID separator from ':' to '|' for robustness - Use per-message ctx instead of channel-level c.ctx in HandleMessage - Distinguish error types: ErrSessionNotFound -> ErrSendFailed (permanent) - Update xiaoyi-agent-sdk dependency

ystyle · 2026-02-28T12:53:28Z

@alexhoshina @nikolasdehor Thank you for the detailed review! I've addressed all the feedback in commit b3ff44f:

SDK License ✅ - Added MIT license to xiaoyi-agent-sdk repository
chatID separator robustness ✅ - Changed separator from : to | to avoid potential conflicts with sessionID content
Context usage ✅ - Now using per-message ctx instead of channel-level c.ctx in HandleMessage
Error wrapping ✅ - Now distinguishing error types:
- ErrSessionNotFound → ErrSendFailed (permanent)
- Other errors → ErrTemporary (transient)

Please let me know if there are any other issues to address. Thanks!

xiaket · 2026-03-01T06:03:37Z

Given that the SDK you are using is a one man show, we would have concern over the supply chain security(I know go has checksums etc). I would be very cautious to move forward.

ystyle · 2026-03-01T07:14:06Z

@xiaket Thank you for raising the supply chain security concern. That's a valid point.

The xiaoyi-agent-sdk is developed following Huawei's official TypeScript SDK: https://developer.huawei.com/consumer/cn/doc/service/openclaw-0000002518410344

The official installation method is:

openclaw plugins install @ynhcj/xiaoyi@latest

Our Go SDK implements the same A2A protocol as the official TS SDK.

I understand the concern about a single-maintainer dependency. A few options to address this:

Transfer SDK to sipeed organization - Move the SDK under the sipeed org for collective maintenance
Vendor the SDK code - Copy the SDK code directly into picoclaw codebase
Add more maintainers - Invite picoclaw maintainers to collaborate on the SDK

What would you suggest as the best approach to move forward?

xiaket · 2026-03-01T07:26:28Z

Thanks @ystyle ! I think @Zepan might be the best person to answer this question ;)

xiaket · 2026-03-01T12:03:05Z

From my personal perspective, I don't think it's fair to ask sipeed/picoclaw to support an SDK that has very little usage.

ystyle · 2026-03-02T06:23:10Z

@xiaket You're right about the current usage. However, Huawei's OpenClaw agent type was just released about two weeks ago. The ecosystem is still very new.

As the first (and currently only) Go SDK for OpenClaw, usage will naturally grow as more developers adopt the platform. This PR would enable picoclaw users to connect to Huawei's XiaoYi ecosystem early.

But I completely understand the concern. Let's wait for @Zepan's input on how to proceed.

Options remain:

Transfer SDK to sipeed org
Vendor the SDK code into picoclaw
Wait for more adoption before merging

Thank you for the thoughtful review! 🙏

ystyle force-pushed the feat/xiaoyi-channel-refactor branch from a4c458f to fd8e4cd Compare February 27, 2026 14:10

ystyle mentioned this pull request Feb 27, 2026

feat(channels): add xiaoyi channel support #843

Closed

alexhoshina reviewed Feb 27, 2026

View reviewed changes

ystyle force-pushed the feat/xiaoyi-channel-refactor branch from b974a00 to ae50335 Compare February 27, 2026 14:42

alexhoshina reviewed Feb 27, 2026

View reviewed changes

ystyle force-pushed the feat/xiaoyi-channel-refactor branch from ae50335 to 693db82 Compare February 27, 2026 16:12

nikolasdehor reviewed Feb 28, 2026

View reviewed changes

fix(channels): address PR review feedback

b3ff44f

- Change chatID separator from ':' to '|' for robustness - Use per-message ctx instead of channel-level c.ctx in HandleMessage - Distinguish error types: ErrSessionNotFound -> ErrSendFailed (permanent) - Update xiaoyi-agent-sdk dependency

sipeed-bot bot added type: enhancement New feature or request domain: channel domain: config labels Mar 3, 2026

               ## 💬 Chat Apps
-              Talk to your picoclaw through Telegram, Discord, WhatsApp, DingTalk, LINE, or WeCom
+              Talk to your picoclaw through Telegram, Discord, DingTalk, LINE, WeCom, or XiaoYi

+              		return nil
+              	}
+              	chatID := fmt.Sprintf("%s:%s", sessionID, taskID)

+              		return fmt.Errorf("xiaoyi reply: %w", channels.ErrTemporary)
+              	}
+              	if err := c.client.SendStatus(ctx, taskID, sessionID, "Completed", "completed"); err != nil {

Conversation

ystyle commented Feb 27, 2026

Summary

Files Changed

Configuration

Related

Uh oh!

alexhoshina Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

ystyle Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

ystyle commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexhoshina Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

alexhoshina Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

alexhoshina Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

alexhoshina commented Feb 27, 2026

Uh oh!

alexhoshina commented Feb 27, 2026

Uh oh!

ystyle commented Feb 27, 2026

Uh oh!

ystyle commented Feb 27, 2026

Uh oh!

alexhoshina commented Feb 27, 2026

Uh oh!

yinwm commented Feb 27, 2026

Uh oh!

ystyle commented Feb 27, 2026

Uh oh!

ystyle commented Feb 27, 2026

Uh oh!

nikolasdehor left a comment

Choose a reason for hiding this comment

Uh oh!

alexhoshina commented Feb 28, 2026

Uh oh!

ystyle commented Feb 28, 2026

Uh oh!

xiaket commented Mar 1, 2026

Uh oh!

ystyle commented Mar 1, 2026

Uh oh!

xiaket commented Mar 1, 2026

Uh oh!

xiaket commented Mar 1, 2026

Uh oh!

ystyle commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ystyle commented Feb 27, 2026 •

edited

Loading